EnigmA Amiga Run 1996 March

home *** CD-ROM | disk | FTP | other *** search

/ EnigmA Amiga Run 1996 March / EnigmA AMIGA RUN 05 (1996)(G.R. Edizioni)(IT)[!][issue 1996-03][Skylink CD IV].iso / earcd / faq / fds-310.lha / FDS-310.examples next >

Wrap

Text File | 1995-10-25 | 15KB | 378 lines

@Start_of_text ======================================================================== EXAMPLES EXAMPLES ======================================================================== 1.0 DEFAULT DESCRIPTIONS ========================= · Example 1.1 --- 8< ------------------------- %DES: Default <Short description> --- 8< ------------------------- This is *THE* simplest form of FDS description, which only contains one single description line. The description in this case is the DEFAULT description (the english description). · Example 1.2 --- 8< ------------------------- %DES: Default <Short description> <Extended description, line 1> <Extended description, line 2> --- 8< ------------------------- This is the same as example 1.1, but with the addition of two lines for the extended description. Please note again that you MUST ALWAYS have a SHORT description. See also next example. · Example 1.3 --- 8< ------------------------- %DES: Default <Extended description, line 1> <Extended description, line 2> --- 8< ------------------------- This example description is a bit wrong. The first "extended" line will be the SHORT description in this example. ALWAYS remember that the very first line of the description text is used as a one-line description. · Example 1.4 --- 8< ------------------------- %DES: Default <Short description> <Extended description, line 1> <Extended description, line 2> $DES: Svenska <Short SWEDISH description> <Extended SWEDISH description, line 1> <Extended SWEDISH description, line 2> $AUT: John Doe --- 8< ------------------------- This is a multi-language description, where the DEFAULT description comes first. It also contains a Swedish description as well as an author keyword informing you who the author is. See also example 1.5. · Example 1.5 --- 8< ------------------------- %DES: Svenska <Short SWEDISH description> <Extended SWEDISH description, line 1> <Extended SWEDISH description, line 2> %AUT: John Doe %DES: Default <Short description> <Extended description, line 1> <Extended description, line 2> --- 8< ------------------------- Here the default description have been moved to the end of the file, but this is essentially exactly the same as example 1.4. · Example 1.6 --- 8< ------------------------- %DES: Svenska <Short SWEDISH description> <Extended SWEDISH description, line 1> <Extended SWEDISH description, line 2> %AUT: John Doe --- 8< ------------------------- Well, this description doesn't even have a default description. How does that work then? Well, it is up to the parsing software to allow the end-user to select if it should use some other description (in this example, a swedish sysop will probably use the swedish description) or if no description should be used at all (an Italian sysop would probably NOT want to use the swedish description). I don't see this as a limitation, but rather the opposite, and I believe that most descriptions will use a default(english) description anyway, so... 2.0 SECTIONS IN EXTENDED DESCRIPTIONS ====================================== NOTE: The examples in this chapter will only show the extended description, NOT the entire description file This is the "template" used in this chapter; --- 8< ------------------------- This is a test of how the use of sections in the extended descriptions should be used. This is the second section. This is actually the fourth section, as the empty line might be considered to be the third. This is not that interesting for the end-user, but might be of help to developers. - This is a list - of features, or - a list of known - bugs... - Anyhow, this "list" is treated the same way as - the above sections, and each of these lines - is actually a section. This means that these - lines are allowed to be wrapped to a defined - linelength. This is the last section to be used, but after this section follows two empty lines, which would've been considered to be valid sections if they hadn't been AFTER the last "real" section (i.e. this section) --- 8< ------------------------- Ok, I will try to explain what is supposed to happen with sections. Each section is used in a way similar to chapters in a book. This means that each section should not interfere with another, which also prevents the wordwrap routine to "mix" sections. · Example 2.1 First, let's take a look at the first two sections; --- 8< ------------------------- This is a test of how the use of sections in the extended descriptions should be used. This is the second section. --- 8< ------------------------- There is a difference between these two sections that might not be that obvious. As you can see, the second section BEGINS with the space in the first position on the row. The space in the first position always mean that a new section begins there. Now, the first section doesn't have this space on the first row, why is that? Well, being the first section it does not NEED a space, because of it BEING the first row in the extended description. Of course, it could have been a space there, it would've meant the same thing. Note though that the OUTPUT of the parser should put a space there, if there was no space there in the first place. · Example 2.2 Let's take a look at the "list" from the template. --- 8< ------------------------- - This is a list - of features, or - a list of known - bugs... - Anyhow, this "list" is treated the same way as - the above sections, and each of these lines - is actually a section. This means that these - lines are allowed to be wrapped to a defined - linelength. --- 8< ------------------------- As these lines begin with a space, they are all divided into separate sections, which prevents them from being wrapped together into an unreadable mess. BUT, each of these lines might be wrapped by itself, IF the end-user specifys a linelength of LESS characters than one of these lines are long. This will probably not be a big problem, but the leading spaces (4 in this case) should remain as they are, i.e. they should not be converted into ONE single space. For example; Wrapped for 35 chars width, the output should look like this: |-------------- 35 ---------------| - This is a list - of features, or - a list of known - bugs... - Anyhow, this "list" is treated the same way as - the above sections, and each of these lines - is actually a section. This means that these - lines are allowed to be wrapped to a defined - linelength. |---------------------------------| ...which I admit, doesn't look very nice, but is the SIMPLE way to wrap text. Developers might choose to do some really fancy stuff when it comes to wordwrapping, but this is the way it should work as a minimum. I mean, intelligent coding could produce the following instead of the above; |-------------- 35 ---------------| - This is a list - of features, or - a list of known - bugs... - Anyhow, this "list" is treated the same way as - the above sections, and each of these lines - is actually a section. This means that these - lines are allowed to be wrapped to a defined - linelength. |---------------------------------| Well, the above examples might be a "worst-case-scenario", as most boards allow descriptions 44 chars or MORE for descriptions. A tip would be to keep any "lists" like the above one UNDER 45 chars in width. · Example 2.3 Trailing "empty" sections. In the very end of the template, the following sections can be found; --- 8< ------------------------- This is the last section to be used, but after this section follows two empty lines, which would've been considered to be valid sections if they hadn't been AFTER the last "real" section (i.e. this section) --- 8< ------------------------- Actually, as I've mentioned before, the empty lines are sections too, but as the two lines in the above example really are unnecessary, I recommend that parsing software strips them from the output. Thus, trailing "empty" sections should be removed from the OUTPUT of any parsing software. 3.0 EXAMPLE DESCRIPTIONS ========================= · Example 3.1 --- 8< ------------------------- %DES: Default MouseTool 3.2, mouse utility. Mouse accelerator, blanker, sound daemon and more useful stuff. %AUT: Steven Parkinson %VER: MouseTool 3.2 (7.6.93) %REV: 37.84 %DAT: 13.6.93 %REQ: Amiga, OS 2.04+ %OBJ: Mouse Utility Commodity %LAN: Locale/English/Deutsch %REP: MTOOL30.LHA MTOOL31.LHA %END: --- 8< ------------------------- Description with only DEFAULT (english) description consisting of a SHORT description (first line) and two EXTENDED description (next two) lines, author info, version, revision and release date. Program requires an Amiga with at least OS 2.04, and supports any language provided a translation is created. It's supplied with English built-in, and German as an option. It has some search keyword attached, which means that a BBS could easily categorize it to a proper area. Furthermore, it supplies information on previous, obsolete, versions, which could now be deleted. · Example 3.2 --- 8< ------------------------- %DES: Default GIF 800x600: Albert Einstein %OBJ: Picture Graphics Painting %FIL: Einstein.gif --- 8< ------------------------- Another very simple description, containing only a SHORT description. · Example 3.3 --- 8< ------------------------- %DES: Elite .------------------------------------------. | UFO Enemy unknown, Vitality fix! | |------------------------------------------| | How to get loads of cash | | and awesome soldiers | | UFO Enemy Unknown | |------------------------------------------| |Start the Game with 2.147.483.647 Credits.| `------------------------------------------' %DES: Default UFO Enemy Unknown, vitality fix. Get LOADS of money and supersoldiers in this great game from MicroProse %REQ: AGA Amiga, UFO Enemy Unknown %OBJ: Game Cheat %END: --- 8< ------------------------- This description contains an "elite"-description, which could contain some ASCII-art by any of the good ASCII-artists out there. This example isn't very extreme but wouldn't have made a good description had it been used as an ordinary description. This is where the %DES: Elite comes into the picture, because it MUST NOT be wrapped, which in turn allows these kinds of descriptions. There is also a DEFAULT description, which follows the usual rules for the descriptions. · Example 3.4 --- 8< ------------------------- %DES: Default Spot 1.3, offline reader supreme The best point-program available for the Amiga. VERY user-friendly! %AUT: Nico François %VER: Spot 1.3 (16.8.94) %REV: 37.4515 %REQ: Amiga 2.04+ %LAN: Locale/English/Dansk/Deutsch/Espanol/Francais/Italiano... %TYP: Shareware, features disabled. %REG: US$30, UK£20, 1000 BEF, 50 DM --- 8< ------------------------- Well, this example is mainly to show the use of the %TYP: and %REG: keywords, which can be used to describe if the software is crippled in any way, and how much it costs to register. Spot, in this case, is Shareware, and some features are disabled in the unregistered version. Other softwares/authors might be Freeware, Cardware, Giftware, Mailware, Callware or whatever... Use it if you want to...:) 4.0 NOTES ON EXAMPLES ====================== Well, it's not that easy for me, knowing the standard inside out, writing things I THINK you might be uncertain of, so if there is something that needs more explaining, please tell me, and I will add more examples. OR, if you want to, send me more examples yourself! - Peter @End_of_text